udisks2 was uploaded recently to Debian sid. With this, people might have seen hidden encrypted disks reappear in Thunar. Hiding disks in udisks was previously done by setting an udev propery. For example, I did this using /etc/udev/rules.d/99-hide-disks.rules:

KERNEL=="sda2", ENV UDISKS_PRESENTATION_HIDE ="1" This is not valid anymore in udisks2, but only the property name has changed. You can simply replace by:

KERNEL=="sda2", ENV UDISKS_IGNORE ="1"

This is an update on the Xfce 4.10 transition to unstable. Most desktop components have been uploaded, built and installed to the archive. We're now currently building and uploading the various goodies, and especially panel plugins. There's a lot of them so it takes some time. Once we'll have finished to build and upload all the goodies, we'll ask for binNMUs on the packages which don't need a sourceful upload but need to be rebuilt against libxfce4util or xfce4-panel 4.10. You can follow the transition status using the release team page. In any case, please be patient while we upload all the packages. Again, no need to report installability issues in unstable for now, we are aware of it and don't need more warnings. We'll fix the fallouts in due time.

Thanks to the release team ACK, I've started uploading Xfce 4.10 to unstable yesterday. For now, I've only pushed Xfce 4.10.1 desktop components, which means people using xfce4 + xfce4-goodies in unstable won't be able to upload at once. That's because panel plugins have a quite hard dependency on the running xfce4-panel, and the communication protocol has changed between Xfce 4.8 and 4.10. So all panel plugins need to be rebuild against the new xfce4-panel. I'll start uploading new releases or packages revisions this evening, and binNMUs will be scheduled for the rest, but it'll take some days. In the meantime, you can safely wait before upgrading xfce4. If you don't use external panel plugins, then you can accept to remove xfce4-goodies and the various xfce4-*-plugins and upgrade to xfce4 4.10. There's no need to report a bug about that situation, we're already aware of it and it's somehow intended, things will settle in a few days.

After some feedback from other people, I have an important update to make on my last post. As I said, what decided me to eventually buy an OpenPGP smartcard was that it supported 4096 bit keys, so it would fit my 4096R/71EF0BA8 key. In the end, it seems it's a little more complicated than that. 4096R keys are indeed supported, as far as signing and authentication are concerned. But encryption keys seem limited to 3072 bits (or maybe more, I didn't test toroughly). When trying to decrypt some stuff encrypted for a 4096R key on the smartcard, gpg fails with some general error . It has already been reported here, but no news since. In my case, it's not that bad, I decided to go for 2048R for all subkeys. But if you desperately need 4096 bit encryption key, OpenPGPv2 smartcards might not be the right solution for you. I have no idea if the problem lies in GnuPG or in the smartcard, and I can't really find much information on this.

A friend of mine recently reminded me of the OpenPGP smartcard v2, and told me that it was perfectly able to handle 4096 bit RSA keys (provided you have GnuPG v2.0.18+). I had the opportunity to play with one a little, and notice it was super easy to use it for ssh authentication, especially since I already use gpg-agent as my ssh-agent (it should be easy to use a purely software authentication key as ssh key with GnuPG 2.1). So I decided to buy two of them and try to switch my main key (0x71ef0ba8) to it. The cards arrived this weekend, and I was able to play with it a little. I didn't log every command I typed, but it was pretty easy, in the end. What I decided to do was to use one smartcard for every day usage, and one only for key signing. So basically, I would generate three (signing, encryption, authentication) subkeys, put them on smartcard 1, then put the primary key on smartcard 2. Then erase the private parts, and only keep them on smartcards. In case it interests people, here the somehow detailed steps. Note that everywhere 'gpg' means 'gpg2' on Debian, we really need GnuPG v2 for correct smartcard handling. You'd better use gpg-agent too, although it doesn't seem mandatory.

1. make a backup! As we're gonna play with private parts (!), it's always a good idea to have backups. And it'll be useful to have one later, in case there's a problem with the smartcards. You can do a copy of your complete ~/.gnupg folder, but I simply did:

   corsac@scapa: umask 066
   corsac@scapa: gpg -o 71ef0ba8.gpg --export-secret-keys 71ef0ba8
   

2. Add three subkeys. Skip this is you already have subkeys (you usually already have an encryption subkey, but I wanted to switch to a new one too) --expert is needed in order to chose capabilities.

   corsac@scapa: gpg --expert --edit-key 71ef0ba8
   gpg> addkey
   Please select what kind of key you want:
      (3) DSA (sign only)
      (4) RSA (sign only)
      (5) Elgamal (encrypt only)
      (6) RSA (encrypt only)
      (7) DSA (set your own capabilities)
      (8) RSA (set your own capabilities)
   Your selection? 8
   Possible actions for a RSA key: Sign Encrypt Authenticate 
   Current allowed actions: Sign Encrypt 
      (S) Toggle the sign capability
      (E) Toggle the encrypt capability
      (A) Toggle the authenticate capability
      (Q) Finished
   Your selection? e
   Possible actions for a RSA key: Sign Encrypt Authenticate 
   Current allowed actions: Sign 
      (S) Toggle the sign capability
      (E) Toggle the encrypt capability
      (A) Toggle the authenticate capability
      (Q) Finished
   Your selection? Q
   RSA keys may be between 1024 and 4096 bits long.
   What keysize do you want? (2048) 
   Requested keysize is 2048 bits
   Please specify how long the key should be valid.
            0 = key does not expire
           = key expires in n days
         w = key expires in n weeks
         m = key expires in n months
         y = key expires in n years
   Key is valid for? (0) 1y
   Key expires at dim. 27 oct. 2013 20:38:44 CET
   Is this correct? (y/N) y
   Really create? (y/N) y
   We need to generate a lot of random bytes. It is a good idea to perform
   some other action (type on the keyboard, move the mouse, utilize the
   disks) during the prime generation; this gives the random number
   generator a better chance to gain enough entropy.
   

   Repeat this for encryption and authentication subkeys. Then save and send the key to keyservers

   gpg> save
   corsac@scapa: gpg --send-keys 71ef0ba8
   

3. Next, we'll switch to the smartcard part. I use a Gemalto PC ExpressCard reader which is perfectly recognized under Debian. You just need few tools:

   root@scapa: ~# apt-get install pcscd scdaemon
   

   Plug the reader, insert the card, make sure it's detected:

   corsac@scapa: gpg --card-status
   Application ID ...: D2760001240102000005000016A10000
   Version ..........: 2.0
   Manufacturer .....: ZeitControl
   ...
   

   You can edit various parameter (name etc.) and change the PINs using gpg:

   corsac@scapa: gpg --change-pin
   corsac@scapa: gpg --card-edit
   

4. Then we'll put the subkeys in the first smartcard. It might be a good idea to export again the private keys for backups.

   corsac@scapa: gpg -o 71ef0ba8.gpg --export-secret-keys 71ef0ba8
   

5. We'll now use the keytocard gpg command to move the private parts on the smartcard:

   corsac@scapa: gpg --edit-key 71ef0ba8
   gpg> key 1 # select encryption subkey
   gpg> keytocard
   gpg> key 2 # select signature subkey
   gpg> keytocard
   gpg> key 3 # select authentication subkey
   gpg> keytocard
   gpg> save
   

   A quick check on the card now reveals that it's populated:

   corsac@scapa: gpg --card-status
   Application ID ...: D2760001240102000005000016A10000
   Version ..........: 2.0
   Manufacturer .....: ZeitControl
   Serial number ....: 000016A1
   Name of cardholder: Yves-Alexis Perez
   Language prefs ...: fr
   Sex ..............: unspecified
   URL of public key : http://www.corsac.net/71ef0ba8.asc
   Login data .......: corsac
   Signature PIN ....: forced
   Key attributes ...: 2048R 2048R 2048R
   Max. PIN lengths .: 32 32 32
   PIN retry counter : 3 3 3
   Signature counter : 7
   Signature key ....: 9745 B022 7323 81FE 9E7E  AFF5 6DDB 53F2 A675 C0A5
         created ....: 2012-10-27 11:24:07
   Encryption key....: F7E0 078F EA1A 5F23 92E0  20B3 A83A D136 D98D 0D9F
         created ....: 2012-10-27 11:27:01
   Authentication key: 8CFD D478 AB4A 16F8 F0EC  CD33 24E2 3B5C CC0E 273D
         created ....: 2012-10-17 14:29:18
   General key info..: pub  2048R/A675C0A5 2012-10-27 Yves-Alexis Perez 
   sec>  4096R/71EF0BA8  created: 2009-05-06  expires: never     
                         card-no: 0005 000016A2
   ssb   4096g/36E31BD8  created: 2009-05-06  expires: never     
   ssb>  2048R/CC0E273D  created: 2012-10-17  expires: 2013-10-27
                         card-no: 0005 000016A1
   ssb>  2048R/A675C0A5  created: 2012-10-27  expires: 2013-10-27
                         card-no: 0005 000016A1
   ssb>  2048R/D98D0D9F  created: 2012-10-27  expires: 2013-10-27
                         card-no: 0005 000016A1
   

6. At that point, the private part is replaced by a stub in the secret keyring, so when you export them, you only export stubs which you can then use anywhere without actually giving your private key. So now is a good idea to export the subkeys so you can import them on other boxes:

   corsac@scapa: gpg -o 71ef0ba8-subkeys.gpg --export-secret-subkeys 71ef0ba8
   

   Note that only the subkeys private parts have been moved to the card, not the primary one, so you're still able to sign keys. Here, you have multiple choices. You can simply erase the private key (and later re-import the stubs) and use the offline copy made above when you need to sign another key.
7. What I did is something else. I've put the primary key on my second OpenPGP smartcard. That way, I won't lose it, it'll be kept safely in my house, but still be on a hardware token where it won't come out. The procedure for doing is so is exactly the same as above. First take a backup (in case you didn't do it first, do it now since after the keytocard command you won't have a backup of your primary key and there'll be no way to extract it from the smartcard. Then put the new smartcard in the reader, edit the key (don't select a subkey) and run the keytocard command. After that, running gpg --export-secret-keys will export the stub and not the private part of your primary key.

In the end, it seems that everything is running fine. Only issue is that scdaemon is sometime not behaving nicely (especially after a card change or or suspend/resume cycle). I didn't yet report a bug but you might want to kill it in case it's stuck. You can also use the authentication subkey for ssh logins. When the card is inserted, the authentication subkey appears automatically (through the magic of gpg-agent):

corsac@scapa: ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EA... cardno:0005000016A1 And now you can add it to your various authorized_keys and use the smartcard for SSH.

It's been six months since Xfce 4.10 has been released. And it's been four months since Wheezy is frozen. Due to this timing (and the fact Squeeze has 4.6 and doing a 4.6 4.10 upgrade needed some tuning in various packages), it was decided to not try to push 4.10 into Wheezy that late in the release cycle. So Xfce 4.10 was uploaded to experimental instead, and as it needs a full rebuild of all panel plugins against 4.10 panel (another reason for not trying to push it to Wheezy), those have not been uploaded. You can try Xfce 4.10 using experimental, but you'll need to remove the xfce4-goodies metapackage and the various depending plugin (since they'll just crash if you try to load them on 4.10 panel). Multiple people asked me (either on IRC, by private or public mail) when 4.10 will be uploaded to unstable and transition to testing. Like last time, the answer is : not before Wheezy is released. Right now, we're more interested in stabilizing Wheezy and squashing the bugs there than adding new ones in unstable. So, if you want to have Xfce 4.10 in Debian sid/testing sooner, then the easiest and fastest way is to fix some release critical bugs so we can release sooner, and then start breaking sid by uploading a whole lot of new stuff there. Note that this is true also for other software like GNOME, KDE stack (I have no idea how to call it these days), the Linux kernel, strongswan or whatever. About development releases of Xfce 4.11 (like the recently released exo 0.9 and Thunar 1.5), well, since we already use experimental for 4.10, there's not much chance they get uploaded anytime soon. We could try to package them and let people build it themselves, or I could host it somewhere on my server for people to try. But as I already said, we're more interested in fixing bug in Wheezy right now, and people interested in finding bugs in Xfce development releases (so they are fixed for the final one) should build it themselves and report everything they find on the Xfce bugzilla. TL;DR: if you care about new, shiny stuff, please help fixing RC bugs in Wheezy.

J rg is a very active contributor within Debian, and has been for a long time. This explains why he holds so many roles (FTPmaster and Debian Account Manager being the 2 most important ones) Better known as Ganneff (his IRC nick), he s not exactly the typical hacker. He has no beard and used to drink milk instead of beers. Check out his interview to learn more about some of the numerous ways one can get involved in Debian, managing its infrastructure and without having to be a packager. Raphael: Who are you? J rg: My name is J rg Jaspert and I m 35 years old working for a small company doing system administration and consulting work for our customers. I m married for a little while now and sometime soon a little Ganneff will be crawling out of my wife. (Whoever didn t think of the movie Alien now is just boring). Raphael: How did you start contributing to Debian? J rg: I started using Debian somewhere around 2000, 2001. Before that I had the misfortune to try SuSE and RedHat, both with a user experience that let me fully understand why people think Linux is unusable. (Due to my work I m in the unfortunate situation to have to use RedHat on two machines. Funny how they are still utter crap and worse than bad toys). And all of this lets get a Linux running here came up because I was trying to find a replacement for my beloved OS/2 installation, which I had for some years. So after I got Debian installed, good old Potato, I got myself active on our mailing lists, starting with the German user one. A bit later I replied to a question if someone can help as staff for a Debian booth somewhere. It was the most boring event I ever visited (very nice orga, unfortunately no visitors), but I got a few important things there:

• a signature from a DD on my key (Hi grisu),
• a discussion with an upstream author with some useful piece of software to package and
• an impression that this can be fun, if there are just some visitors for an event. So I tried again and did help as staff on a LinuxTag booth a while later.

The software I packaged, found me a sponsor and voila, maintainer I was. Some more packages got added and at some point my sponsor turned out to be my advocate. The NM process run around 2 months, and mid April 2002 I got THE MAIL. Raphael: Some Debian developers believe that you have too many responsibilities within Debian (DAM, FTPMaster, Debconf, Partners, Planet Debian, Mirrors, ). Do you agree that it can be problematic, and if yes, are you trying to scale down? J rg: It s DebConf, tssk. And yes, I do have some extra groups and roles. And you even only list some, leaving out all I do outside Debian. But simply counting number of roles is a plain stupid way to go. Way more interesting is how much work is behind a role and how many other people are involved. And looking at those you listed I don t see any I am a SPOF. Let s look at those you listed: DAM: Here I did start out assisting James to get the huge backload down which had accumulated over time. Nowadays I am merely the one with the longest term as DAM. Christoph Berg joined in April 2008 and Enrico Zini followed during October 2010, both very active. Especially Enrico, lately with the redesign of the NM webpages. FTPMaster: The basic outline of the FTPMaster history is similar to the DAM one. I joined as an assistant, after the oh-so-famous Vancouver meeting in 2004. Together with Jeroen, we both then got the backload down which had accumulated there. He did most of the removals while I had a fun time cleaning up NEW. And we both prepared patches for the codebase. And in 2007, as the last action as DPL, Sam made me FTPMaster. Since then I haven t been alone either. In fact we have much more rotation in the team than ever before, which is a good thing. Today we are 3 FTPMasters, 4 FTP Assistants and 1 Trainee. Though we always like new blood and would welcome more volunteers. DebConf: I am very far outside the central DebConf team. I am not even a delegate here. Currently I am merely an admin, though there are 4 others with the same rights on the DebConf machines. I ve not taken any extra jobs this year, nor will I. Probably for next year again, but not 2012. Planet: I am one of three again, but then Planet is mostly running itself. Debian developers can just edit the config, cron is doing the work, not much needed here. Occasional cleanups, every now and then a mail to answer, done. In short: No real workload attached. Mirrors: My main part here is the ftpsync scriptset. Which is a small part of the actual work. The majority of it, like checking mirrors, getting them to fix errors, etc. is done by Simon Paillard (and since some time, Raphael Geissert is active there too, you might have heard about his http.debian.net). Having said that, there is stuff I could have handled better or probably faster. There always is. Right now I have 2 outstanding things I want to do a (last) cleanup on and then give away. Raphael: You got married last year. I know by experience that entertaining a relationship and/or a family takes time. How do you manage to combine this with your Debian involvement? J rg: Oh well, I first met my wife at the International Conference on OpenSource 2009 in Taiwan. So OpenSource, Debian and me being some tiny wheel in the system wasn t entirely news to her. And in the time since then she learned that there is much more behind when you are in a community like Debian, instead of just doing it for work. Even better that she met Debian people multiple times already, and knows with who I am quarreling Also, she is currently attending a language school having lots of homework in the evening. Gives me time for Debian stuff. How that turns out with the baby I have no idea yet. I do want to train it to like pressing the M key, so little-Ganneff can deal with NEW all on its own (M being Manual reject), but it might take a day or twenty before it gets so far. Raphael: Thanks to the continuous work of many new volunteers, the NEW queue is no longer a bottleneck. What are the next challenges for the FTPmaster team? J rg: Bad link, try this one. Also, no longer sounds like its recent. It s not, it s just that people usually recognize the negative only and not the positive parts. Well, there are a few challenges actually. The first one, even if it sounds simple, is an ongoing one: We need Debian Developers willing to do the work that is hidden behind those simple graphs. Yes, we are currently having a great FTP Team doing a splendid work in keeping that queue reasonably small this is a/THE sisyphean task per excellence. There will always be something waiting for NEW, even if you just cleaned the queue, you turn around and there is something else back in already. Spreading this workload to more people helps not burning one out. So if one or more of the readers is interested, we always like new volunteers. You simply need to be an uploading DD and have a bit of free time. For the rest we do have training procedures in place. Another one is getting the multi-archive stuff done. The goal is to end up with ONE host for all our archives. One dak installation. But separate overrides, trees, mirrors, policies and people (think RMs, backports team, security team). While this is halfway easy to think of in terms of merging backports into main it gets an interesting side note when you think of merging security into main . The security archive does have information that is limited to few people before public release of a security announce, and so we must make sure our database isn t leaking information. Or our filesystem layer handling. Or logs. Etc. Especially as the database is synced in (near) realtime to a DD accessible machine. And the filesystem data too, just a little less often. There is also a discussion about a good way to setup a PPA for Debian service. We do have a very far developed proposal here how it should work, and I really should do the finishing touches and get it to the public. Might even get a GSoC project on it. So far for some short to middle term goals. If you want to go really long term, I do think that we should get to the point where we get rid of the classical view of a source package being one (or more) tarballs plus the Debian changes. Where a new version requires the full upload of one or more of those parts of the source package. I don t know exactly where it should end up. Sure, stuff like one central DVCS, maintainers push there, the archive generates the source tarballs and prepares the mirrors do sound good for a quick glance. But there are lots of trouble and pitfalls and probably some dragons hidden here. Raphael: The Debian repositories are managed by DAK (Debian Archive Kit) which is not packaged. Thus Debian users pick tools like reprepro to manage their package repositories. Is that how things should be? J rg: Oh, Mark Hymers wants to do a package again. More power to him if he does, though yes, DAK is not exactly a quick-and-easy thing to install. But nowadays it is a trillion times easier than the past thanks to Mark s work people can now follow the instructions, scripts and whatever they find inside the setup directory. Still, it really depends on the archive size you are managing. A complex tool like dak does not make sense for someone who wants to publish one or a dozen of his own packages somewhere. Thats just like doing a finger amputation with a chainsaw it certainly works and is fun for the one with the chainsaw but you probably end up a little overdoing it. I myself am using dpkg-scan[packages sources] from a shell script but also mini-dinstall in places (never got friend with reprepro when I looked at it). Works, and for the few dozen packages those places manage it is more than enough. Also, using dak forces you into some ways of behaviour that are just what Debian wants but might not be what a user wants. Like inability to overwrite an existing file. One of the reasons why mentors.debian.net won t work with dak. Or the use of a postgres database. Or that of gpg. Sure, if you end up having more than just a dozen packages, if you have many suites and also movement between them, then dak is sure a thing to look at. And how should things be : however the user and admins of that certain install of reprepro, mini-dinstall, dak, whatever want it. This is not one-tool-for-all land Raphael: What is the role of Debian Account Managers (DAM)? Do you believe that DAMs have a responsibility to shape Debian by defining limits in terms of who can join and what can be done within Debian? J rg: Quote from https://lists.debian.org/debian-devel-announce/2010/10/msg00010.html:

The Debian Account Managers (DAM) are responsible for maintaining the list of members of the Debian Project, also known as Debian Developers. DAMs are authoritative in deciding who is a member of the Debian Project and can take subsequent actions such as approving and expelling Project members.

Now, aside from this quote, my OWN PERSONAL OPINION, without wearing anything even vaguely resembling a DAM hat: DAM is the one post that is entitled to decide who is a member or not. Usually that is in the way of joining (or not), which is simple enough. But every now and then this also means acting on a request to do something about whatever behaviour of a Debian Project member. I hate that (and i think one can easily replace I with WE there). But it s our job. We usually aren t quick about it. And we don t act on our own initiative when we do, we always have (numerous) other DDs complain/appeal/talk/whatever to us first. The expulsion procedure , luckily not invoked that often, does guarantee a slow process and lots of input from others. Are we the best for it? Probably not, we are just some people out of a thousand who happen to have a very similar hobby Debian. We aren t trained in dealing with the situations that can come up. But we are THE role inside Debian that is empowered to make such decisions, so naturally it ends up with us. Raphael: You did a lot of things for Debian over the years. What did bring you the most joy? Are there things that you re still bitter about? J rg: The most joy? Hrm, without being involved in Debian and SPI I would never have met my wife.
Or my current job. Or a GR against me. Not many running around with that badge, though I m still missing my own personal Serious problems with Mr. Jaspert thread. Bad you all.
Or visited so many places. Think of all the DebConfs, QA meetings, BSPs and whatever events.
Or met so many people.
Or learned so many things I would never even have come near without being DD. Raphael: Is there someone in Debian that you admire for their contributions? J rg: Yes.

---

Thank you to J rg for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

One comment Liked this article? Click here. My blog is Flattr-enabled.

Fresh from the oven, monthly report of what I've been working on as DPL during January 2012.

---

Dear Developers,
here is another monthly report of what happened in DPL-land, this time for January 2012. There's quite a bit to report about --- including an insane amount of legal-ish stuff --- so please bear with me. Or not. Legal stuff

• Webmaster heroes have decided to tackle the long standing issues of copyright and licensing of the Debian website. I've accepted to help them out in reaching consensus with license choice and I'm happy to report that we've managed to pick a DFSG-free license (BSD-ish) for future contributions. Webmasters will soon contact contributors to re-license old contributions (or get rid of them), so hopefully will have a DFSG-free website RSN. Many thanks go to David Pr vot for successfully tackling such a can of worms.
• I've sought a second legal advice on the constraints that trademarks (might) impose on the work-flow of a distro like Debian. Luckily, it is coherent with one I've sought in the past so I'm now in condition to wrap up the "trademark vs DFSG" thread on -project with the missing legal information. Hopefully, I'll find time to do that sometime next week.
• I've restarted discussions with the Debian France association so that they can become a Debian Trusted Organization (as per Constitution 9.3). Members of the board of the association seem to be interested and I'm positive it could happen fairly soon. The importance of this is that we could use a back-up association in Europe to hold Debian assets, to complement the services that FFIS are already offering us.
• Thanks to the contributions of Benjamin Mako Hill and SPI lawyers, I've now what I consider a final draft of a trademark policy for Debian trademarks. Before proposing it to you, I'm waiting for some feedback from another umbrella organization for Free Software projects, that is working on a trademark policy for all their associated projects. As many Free Software projects are seeking trademark protection these days, I see benefits in having uniform (and sane!) policies. I hope to be able to gather the feedback I still miss this week-end at FOSDEM, and let you know shortly after that. Once this is done, we'll also be able to (finally!) relicense all kinds of Debian logos under a DFSG-free license. On this front, I've also updated http://www.debian.org/trademark with the information needed to contact us about trademark usage; hopefully it'll reduce the burden of answering to such inquiries.
• With the help of Kenshi Muto, Fumitoshi Ukai, Ishikawa Mutsumi, Shuzo Hatta, and Yasuhiro Araki we've started the process to move the Debian trademark in Japan from individuals (who are present or past members of the Debian JP association) to SPI. That would help dealing with these matters, as well as ensure that important Debian assets are held by Debian Trusted Organizations.
• I remind you that we've an ongoing complaint with the current registrant of debian.eu, domain that we believe Debian should legitimately own. Lawyers at SPI has now formally contacted the current owner and hopefully we'll be able to solve the issue amicably in the next months.
• Some of the past legal advice I sought for PPA came handy in a discussion on the legal risks of running a service like mentors.debian.net, hopefully addressing part of the issues in turning that into mentors.debian.org
• Patent policy for the Debian archive is now ready as well and I also have a patch for the website ready to be merged. I'm just waiting for the final blessing from SPI (lawyers) to go ahead and publish it.

Most of the above wouldn't have been possible without the precious help of folks at SFLC working for SPI and Debian. Be sure to thank SFLC for what they're doing for us and many other Free Software projects. Coordination Nobody stepped up to coordinate the artwork collection for Wheezy I've mentioned last month, so I've tried to do a little bit of that myself. The -publicity team is now preparing the call for artwork and hopefully we'll send it out RSN. In case you want to help, there is still a lot of room for that; just show up on the debian-desktop mailing list. Sprints A Debian Med sprint has happened in January, and Andreas Tille has provided a nice and detailed report about it. Some more sprints are forthcoming this spring, how about yours? Money

• We got from SPI a prepaid and rechargeable credit card that we can use for expenses or other kind of guarantees. Many thanks to Michael Schulteiss, SPI treasurer, for his help with that. Using it, we've redeemed 10k$ of credits offered to us by Amazon, that (thanks to ongoing work by Lucas Nussbaum) we're going to use to make our QA rebuilds independent from the underlying computing infrastructure.
• Thanks to the help of Luca Capello, we advanced quite a bit on forming the Debian Event Box kit that should make it easier to set up Debian booth at FOSS events. We bought the machine for it (for about ~755 CHF) and the box to contain it will soon be on its way as well. If you're at FOSDEM, tend to the Debian booth to check it out (and possibly help out with the technical setup).
• We've got quite a bit of donations during the December holidays. I've took the chance to thank donors, discuss what we do with donations and the status of publishing periodic Debian budgets.
• Pinged by Yves-Alexis Perez, I've now properly documented the fact that DDs are welcome to apply for hardware sponsoring, in case the hardware can be used to help/improve their Debian work. As suggested by Yves-Alexis, you can also advocate other DDs for hw sponsoring.
• Given hardware invariably age and that we can afford it, I've prodded DSA to prepare a general hardware replacement plan for our machines. Planning will go on this week-end and FOSDEM (thanks to Martin Zobel-Helas and Faidon Liambotis for their presence here) and I hope to have an approved machine replacement plan well before the end of the current DPL term (although I'm usually optimist...).

Important stuff going on Other important stuff has been going on in various area of the project in January. I'd like to point your attention to a couple of things:

• People active on debian-mentors have proposed an improved work-flow to deal with sponsoring/mentoring requests, based on the usage of a new pseudo package "sponsorship-requests". Thanks to Ansgar Burchardt, Jakub Wilk, Arno T ll, and Gregor Herrmann for working on this.
• Raphael Hertzog has kickstarted work on DEP-2, as a way to rationalize the flow of package-related information that (co-)maintainers get. Discussion about the idea are ongoing on the debian-qa mailing list.

Miscellanea

• Work has further progressed in reaching out to companies with an interest in giving support for, and contributing to Debian. Thanks to Alexander Wirt the technical work is now done and some sort of governance policy has been decided. Further step for me is to announce it properly hoping to reach out to as many interested companies as possible. I hope to finalize that in the next month. (If you're working for such a company and you happen to read this, feel free to reach out to me already.)
• I've completed an old todo item setting up and documenting titanpad.debian.net, service that has been requested for collaborative work during various kinds of online events. Help is welcome to help administering the service (see doc).
• SPI has clarified the role of project representatives and, as a consequence of that, I (as DPL) no longer receive SPI board discussions addressed to board@spi. That is good not only for the sanity of my inbox, but also because it puts all projects affiliated to SPI at the same level of communication within SPI. Thanks to Robert Brockway for his work on this.

In the unlikely case you've read thus far, thanks for your attention! Happy Debian hacking.

---

PS as usual, the boring day-to-day activity log is available at master:/srv/leader/news/bits-from-the-DPL.*

A few days ago Yves-Alexis Perez asked me how many hardware sponsorship request I usually get from Debian Developers, that is how many people ask me to use Debian money to buy material that can improve their work on Debian and indirectly Debian itself. The answer is "too few".
Making it easier for our developers to improve Debian is a worthwhile investment of money donated to Debian. Of course such a use of money should be motivated (i.e. you should be able to justify how the material you're asking for would improve Debian and why it should be Debian paying for it) and transparent (i.e. you should periodically report about what you're doing with material that Debian has bought for you to use). The above two principles are what I've tried to convey in a new section of the sponsoring guidelines wiki page I've been maintaining for a while. Comments and improvements highly welcome! Equally welcome are advocacy messages for hardware sponsoring to other fellow Developers, as suggested by Corsac.

Our Dear Project Leader, Stefano Zacchiroli, regularly mentions the fact that there's an amount of Debian money available for hardware sponsoring of Debian developers, but it seems that not much people benefit from it. Each time I saw one of this reminder, I wonder if I should apply, and the anser is usually no. The fact is that I don't think any new laptop or desktop to do my Debian stuff, and the last time I bought a box (my x201s last summer) it was not really specifically for Debian tasks so I didn't dare to ask (not to mention the fact I bought it because I did have the money to do so). And I think this is mostly the problem. I might be wrong, but I think that most people which could benefit from this just don't dare asking or don't estimate themselves eligible for it. When I saw Ben Hutchings post, where the first thing he says is about how hardware is expensive, I thought hey, he should get some Debian money for buying new hardware: building kernel is really time consuming and having multiple powerful cores, more ram and fast disks/SSDs really helps . Turns out that Ben just didn't really want to spend too much money there, but the case still stands. We also see from time to time people saying they'll be offline for a while because of broken laptop or something like that. Once again, maybe those people wouldn't mind some help from the Debian project, and maybe they just don't think about asking, or they don't dare. So thinking about it a bit more, I think I wouldn't dare asking money for myself, but maybe I could dare asking money for other people (this is a bit like the flattr posts by Rapha l Hertzog, where he incited people to give money to projects he liked). If I'm not alone in this case, maybe those Debian developers who think some of their peers would benefit some hardware could drop them a mail with leader@ on copy, to propose just that. No need for huge publicity on that (in order to not embarass people), though the transparency rules still apply when it comes to Debian money.

I received recently a mail about my attempt to provide Grsecurity kernels in Debian. The sender found the bug by accident, and asked me why I didn't do some more publicity here. So here we are. I won't go into details on what grsecurity is, it's fairly complex. But it's basically a hardening patch for the Linux kernel, with three main components:

• the PaX patch, which purpose is to harden the memory layout of the Linux kernel and improve existing options: enforcing of non-executable memory pages (userland and in kernel), W^X (no page marked as writable and executable), ASLR, prevention of invalid userland pointers dereference, copies between userland and kernel memory
• RBAC (Role Based Access Control), an implementation of Mandatory Access Control
• various hardening features: /proc restrictions, chroot restrictions, kernel symbols hiding etc.

A lot of this touches low level stuff in the kernel, especially memory management. Ideally this patch would be pushed upstream, but Brad Spengler (grsecurity main developper) already said he wasn't interested in upstreaming it and upstream already said the patch was too huge and invasive to include it like that (especially since the original authors aren't interested in maintaining it upstream). There's an ongoing effort to split the patch and merge things little by little, but in the meanwhile having a mid-term solution would be nice. I know Debian users rebuilding grsecurity-patched kernels themselves, and I know some of them would appreciate having them included in the Debian kernel. Fortunately, the linux-2.6 source package has a nice feature which is called featureset. Basically it's a way to build some (binary) packages using a different set of patches and a different config. For example this was used to provide xen/openvz/vserver patchsets, and is now used to provide rt kernels. So I though it'd be nice to provide a grsec featureset, and starting doing the work. I have a working setup for producing those kernels, so I've opened a wishlist bug against the kernel (#605090) to have this merged. Those packages follow the sid kernel. There's an ongoing work for Squeeze, but it's a bit harder there because both the grsecurity patchset and the Debian kernel ship a whole lot of backports to the Linux kernel, meaning the grsecurity patch doesn't apply directly to the Debian source package. Basically I need to remove some of the hunks (since they are already applied to the source) and port some others (since there are some backported code not present in the vanilla 2.6.32, for example the drm code). Until the patches are merged and the bug is closed, I host some of the built packages at:

deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/ The repository is signed by my key which you can add to your apt setup using apt-key add. If you want to rebuild the packages yourself, here's the method:

mkdir kernel-grsec
cd kernel-grsec
svn checkout svn://svn.debian.org/svn/kernel/dists/sid/linux-2.6
git clone git://anonscm.debian.org/users/corsac/grsec-patches.git
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.bz2
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.bz2.sign
gpg --verify linux-3.0.tar.bz2
cd linux-2.6
apt-get build-dep linux-2.6
export QUILT_PATCHES=../grsec-patches
quilt push -a
python debian/bin/genorig.py ../linux-3.0.tar.bz2
debian/rules orig
fakeroot debian/rules source
fakeroot make -f debian/rules.gen binary-arch_amd64_grsec_amd64 You could also do dpkg-buildpackage, pdebuild or whatever. Kernel handbook is a nice reading too if you want more information on how to rebuild Debian kernels. The quilt push -a may fail if you checkout an svn version more recent than mine. I try to keep patches up to date but I usually have some delay. Note that installing the kernel will require installing linux-grsec-base package. Binary is not yet available on my mirror but you can easily build it. Source can be found on git.debian.org. If you're interested by this, don't hesitate to mail me or the bug.

The issue This morning (while I was running late for an appointement) I had a very weird stuff happening on my Thinkpad T61 laptop. Since I recently offered myself a shiny Thinkpad x201s, I have to admit I don't use much my T61 anymore. But this morning I had to print a page (for this appointement) and, as I didn't yet configured my printer on the x201s, I went to the T61. But I noticed that the network was down. I've tried quickly on wireless but, bad luck, my current wifi setup selects the channel automatically and it prefers choosing channels which aren't available in the US. Guess what, my T61 comes from the US and has those channels completely disabled, so no wireless available either. The investigation I first tried to

modprobe -r e1000e
modprobe e1000e to see if it fixed the problem, but it didn't. Worse, the interface disappeared and never reappeared. I tried to reboot but it didn't fix the problem, the link was still down. Running really late, I put the file on a usb key and printed it from the powerbook and postponed the fix for later. Now, this evening, I tried to investigate a bit more. Symptoms weren't only that the nic wasn't working, but there was a high load on the system (1-2 at idle), unresponsiveness every second or so, and watching top I could see spikes of high cpu usage for the kworker kernel thread. Typing that on google you can find a lot of people running on this issue, usually starting around kernel 2.6.36 or 2.6.37. Now, I might have upgraded the kernel recently to 3.0.0-4, but that didn't look related since the problem first appeared when the laptop was up and running. And I tried to reboot under 2.6.39, 2.6.38 and even 2.6.32 and the problem was still present. Each time, unloading the module would fix the problem, but loading it again wouldn't make the interface reappear. People advised to boot with pcie_ports=compat but that didn't do anything. I tried to boot without intel_iommu=force (disable Intel Vt-d) and pcie_aspm (Active State Power Management) but nothing either. Considering a userland issue, I've tried to boot a grml live distro (always keep a grml.iso in your /boot, extlinux-update will even put it in your menu automatically), and the problem was still present. So not a Debian kernel issue, not a userland issue, only thing left was the laptop. I didn't update the Bios recently, so I wondered exactly what could be the problem. I started to feel a little bad, since I still really like that laptop, and that I already decided to lend it to my sister since her own T61 is sitting with a dead system board in my shelf. I know she might have some negative waves, but she was not even landed when the problem first appear. The fix Then I had a flash. It's not mystery that I'm used to break network cards, and I had the bright idea to shutdown the laptop, disconnect AC and battery, then let it idle a bit. I even tried the secret Thinkpad power button code but I think it's unrelated. Then I re-plugged the battery, booted to grml and the issue was gone. I rebooted on the standard Debian and the link was up, network was working. So what happenned? The (tentative) explanation My guess is that, somehow, the network card firmware has an issue and choked on something (a network frame or an attack exactly like the one we demonstrated on ASF firmware). In fact, no, I don't think it's the e1000e firmware. My T61 comes with Intel vPro, which includes AMT (Active Management Technology), a remote management solution a bit like ASF but more advanced. As far as I know, AMT firmware always runs, even when it's disabled, it's just completely idle. Idle, but in this case I think it choked on something, and a reboot isn't enough to restart the AMT firmware. But a real hard reset without any power seems to do the trick. What next? Well, a part of me is pretty scared, but another is just bored. I mean, we know about that, that's exactly the kind of issue we are warning people of. I have no idea what exactly happened, and there's no way I'll be able to reproduce that, but I'm pretty sure it's something lying at a pretty low level in the platform, and which can severely disable your workstation. Now if it happens again I won't lose too much time on this. TL;DR: helping other people In case you came here because you searched on google terms like kworker cpu usage , e1000e, interrupts, it might be a good idea to first reboot on a live CD to eliminate installation issues, then shutdown the laptop, remove the battery and let it few seconds idle. This might be enough to reset something inside and fix the situation.

Brent S. Elmer reported the Debian bug #640000 on Thursday September 1st, against evolution. Bug #630000 was reported as of June 10th. This time, it took a little bit more than 2.5 months for 10,000 bugs. This #640000 bug was indeed "fixed" very quickly as it turns out it was not a bug..:-).. Congratulations to Corsac for fixing it..:-)

[UPDATE]: A reader from planet debian (thank you Ross!) just made me noticed that this was definitely not useful. On the (standard) intel documentation page, there's some icons on the top right, like stuff for social networks (facebook, linkedin, twitter and some other), a print icon and a down arrow which I didn't notice at all but which is a direct download link to the PDF. Sorry Intel for doubting you! Starting recently, Intel has started to provide documentation using a flash pdf viewer (example here). This is really painful. I personnaly don't use flash (the flash player is not installed on most of my boxes), I have concerns over flash security wise and I don't like the fact it's proprietary, that the x86_64 version lags behind etc. On top of that, just *using* the flash pdf viewer is painful. It's slow, you're restricted to your browser, search is inexistent, you can't save them for reading them offline. Trying to dig a little inside the Intel website, I had a thought. Who in the world can't use flash? Linux people, yes (at least some of them) but nobody cares. But iPhone/iPad users don't have flash player on their OS, meaning they can't read Intel docs. Or can they? Thanks to the Inspect element tool in webkit browsers, one can easily watch the above website and see something interesting. The div containing the flash applet is style like:

<div id="viewerPlaceHolder" class="nonipad">

This is the eighth Debian XSF News issue. For a change, I m going to use a numbered list, which should help telling people which item to look for when pointing to a given URL. Feel free to let me know if that seems like a nice idea or whether that hurts readability. Also, it was prepared several days ago already, so I m publishing it (with the needed bits of polishing it still needed) without mentioning what happened in the last few days (see you in the next DXN issue!).

1. Let s start with a few common bugs reported over the past few weeks:
   • The server can crash due to some X Font Server (XFS) issue as reported upstream in FDO#31501 or in Debian as #616578. The easy fix is to get rid of FontPath in xorg.conf, or to remove the xfs package. It s deprecated anyway.
   • Xdm used to crash when started from init, but not afterwards (#617208). Not exactly fun to reproduce, but with the help of a VM, bisecting libxt to find the guilty commit was quite easy. After a quick upload with this commit reverted, a real fix was pushed upstream; a new upstream was released, packaged, and uploaded right after that.
   • We ve had several reports of flickering screens, which are actually due to upowerd s polling every 30 seconds: #613745.
   • Many bug reports were filed due to a regression on the kernel side for the 6.0.1 squeeze point release, leading to cursor issues with Intel graphics: #618665.
2. Receiving several similar reports reminded me of the CurrentProblemsInUnstable page on the wiki, which is long unmaintained (and that s why I m not linking to it). I m not exactly sure what to do at this point, but I think having a similar page on http://pkg-xorg.alioth.debian.org/, linked from the how to report bugs page would make sense. Common issues as well as their solutions or workarounds for stable should probably go to the FAQ instead.
3. As explained in DXN#7, we re waiting for the kernel to migrate to wheezy. The 2.6.38 upstream release was quickly pushed to unstable, which is great news, even if it s not really ready yet (since it s still failing to build on armel and mips).
4. I ve been using markdown for our documentation, basically since it looked sufficient for our needs, and since I ve been using it to blog for years now, but it had some limitations. I ve been hearing a lot of nice things about asciidoc for a while (hi, Corsac!), so I gave it a quick shot. Being quite happy with it, I converted our documentation to asciidoc, which at the bare minimum buys us a nice CSS (at least nicer than the one I wrote ), and with automatic table of contents if we ask for it, which should help navigating to the appropriate place. A few drawbacks:
   • The syntax (or the parser s behaviour) changed a lot since lenny s version, so updating the online documentation broke badly. Thanks to the nice Alioth admins, the version from lenny-backports was quickly installed and the website should look fine.
   • The automatic table of contents is generated through JavaScript, which doesn t play nicely with wkhtmltopdf (WebKit-based HTML to PDF converter), since the table of contents gets pixelated in the generated PDF documents. We could use a2x to generate documents through the DocBook way, but that means dealing with XSL stylesheets as far as I can tell; that looks time-consuming and a rather low-priority task. But of course, contributions are welcome.
5. When I fixed missing XSecurity (#599657) for squeeze, I didn t notice the 1.9 packages were forked right before that, so were affected too. I fixed it in sid since then (and in git for experimental). I noticed that when Ian reported a crash with large timeouts in xauth calls, which I couldn t reproduce since untrusted cookies without XSecurity don t trigger this issue. I reported that upstream as FDO#35066, which got marked as a duplicate of (currently restricted) FDO#27134. My patch is currently still waiting for a review.
6. Let s mention upcoming updates, prepared in git, but not uploaded yet:
   • mesa 7.10.1, prepared by Chris (RAOF); will probably be uploaded to experimental, unless 7.10 migrates to testing first, in which case that update will target unstable.
   • Intel driver: Lintian s been complaining about the .so symlinks for a while, and I finally gave it a quick look. It seems one is supposed to put e.g. libI810XvMC.so.1 in /etc/X11/XvMCConfig to use that library, so the symlinks are indeed not needed at all, and I removed them.
   • Tias Guns and Timo Aaltonen introduced xinput-calibrator in a git repository; that s a generic touchscreen calibration tool.
7. Here come the updated packages, with uploader between square brackets (JVdG = Julien Viard de Galbert, Sean = Sean Finney). For the next issue, I ll try to link to the relevant entries in the Package Tracking System.
   • [KiBi] libxt: to unstable, as mentioned above, with a hot fix, then with a real fix.
   • [KiBi] synaptics input driver: to unstable and experimental, fixing the FTBFS on GNU/kFreeBSD.
   • [KiBi] xterm: new upstream, to unstable.
   • [KiBi] libdrm: new upstream, to experimental. A few patches to hide private symbols were sent upstream, but I ve seen no reactions yet (and that apparently happened in the past already).
   • [KiBi] xorg-server 1.9.5rc1 then 1.9.5, to unstable.
   • [KiBi] xutils-dev to unstable: the bootstrap issue goes away, thanks to Steve s report.
   • [KiBi] libxp to unstable, nothing fancy, that s libxp
   • [KiBi] keyboard input driver: mostly documentation update, to unstable and experimental.
   • [KiBi] mouse input driver: fixes BSD issues, to unstable and experimental.
   • [KiBi] intel video driver: to experimental, but the debian-unstable branch can be used to build the driver against unstable s server.
   • [KiBi] xfixes: protocol to unstable, and library to experimental (just in case); this brings support for pointer barriers.
   • [JVdG] openchrome video driver: Julien introduced a debugging package, and got rid of the (old!) via transitional package. He also performed his first upload as a Debian Maintainer. Yay!
   • [KiBi] siliconmotion video driver: to unstable.
   • [KiBi] pixman: new upstream release candidate, to experimental
   • [Sean] last but not least: many compiz packages to experimental.

Since the last post, few things did happen. Basically, it's still not the right time for Debian users to upgrade to Xfce 4.8. We eventually managed to upload the whole desktop part (except the xfce metapackage) to experimental and we did upload some of the goodies too. Licensing issues have been solved so the concerned packages have been uploaded, and we're right now waiting on the three packages sitting in NEW.

• garcon is really mandatory for Xfce 4.8 since it implements the menu library, used by xfce4-panel, xfdesktop and xfce4-appfinder;
• thunar-vfs is needed if you want to keep the goodies not yet ported to the new thunar gio-based API (right now that means squeeze, the archiver, not the distribution);
• tumbler is a replacement for thunar-thumbnailers, implementing a standard thumbnailing interface, so it's possible to skip it for now.

So you'll need to be a little more patient and kindly wait for our ftp-masters to process the (quite huge) NEW backlog. After that we'll need a bit more time in experimental to test upgrade cases, then we'll do an upload to unstable of the whole desktop part and the whole goodies. Upgrading to xfce4-panel 4.8 means *all* plugins need to be rebuilt too, so that means a huge upgrade and a quite large transition to handle for the release team, so we'll have to schedule the unstable upload with them in order not to break all their plans (yes, we try to be good Debian citizens) So please be patient, but you'll see Xfce 4.8 in unstable in a not too distant future. I'll put an update here when we'll need brave volunteers willing to break their systems by doing upgrade tests. [UPDATE]: garcon, thunar-vfs and tumbler were just accepted into experimental, thanks to our ftp-masters. Now we'll synchronize with release team and upload to unstable when possible.

Now that Squeeze has been released, we (the pkg-xfce group) are in the process of uploading 4.8 to Debian. And we are uploading it to experimental for good reasons. Not that 4.8 is broken, but the packages are, and we're aware of it. Some packages are still in NEW, some are not uploaded because of some licensing issues, some have not been uploaded because we didn't yet have the time. What does this mean for you? That you should *not* upgrade to Xfce 4.8. Not all packages will be upgraded, and mixing 4.6 and 4.8 is a bad idea. We don't know yet what will happen (and that's the whole point of uploading to experimental), and it seems that there are issues indeed. So unless you're willing to fix the problems, don't upgrade to 4.8. It's not complete and it *will* break your install. I wouldn't recommend building and installing from our svn repository (for the sames reasons) nor from another (since upgrade path won't be guaranteed and we won't be able to fix them for you). So please be patient, we will upload 4.8 to unstable at one point, and there will still be polishing to be made if you want to help.

These days, I've been used to a very specific $EDITOR usage. I use my (Xfce) workspaces as context switch. Basically, each time I need to start a new activity I open a new workspace, open some terminals, maybe a browser, an editor (gvim) window etc. Then when I'm done, I delete that workspace. I can have multiple activities at once, and switch from one to another depending on various stuff. On those workspaces, I'd like to be able to have only one editor window, even when I open new files using gvim foo.c . But I'd like to have one editor window per workspace, not one global editor, since I'd like the editor to be context-specific too. I recently heard about the gvim remote stuff, and I've came with the following gvim function (zsh syntax):

function gvim()
desktop=$(xprop -root -notype -f _NET_CURRENT_DESKTOP 0c '$0+\n' _NET_CURRENT_DESKTOP)
if [ "$#" -ge "1" ];
then
gvimargs="--remote-tab-silent"
fi
=gvim --servername $desktop $gvimargs $*
The xprop trick is a hackish way to stick one gvim window per workspace, it might need to be adjusted if one has a two monitors setup and want to be able to have one editor per monitor per workspace. Basically, that snippet checks if a gvim server already exists with the current workspace name. If yes, it opens the file(s) in it, if not it run a new gvim server and opens the file there. It works more or less fine, but it has one problem: it fails badly when one needs to give args to the gvim call. Those args are usually placed *before* filenames, so in my case it won't work. One way to fix this would be to loop on all the args, check if the arg is an existing file, in case add it to $files. If not, add it to $args, then call gvim with the correct order. Works, except when you want to edit a new file, where you're back to point one. All in all, it'd work, but it's not really a nice way to do it, imho. So I'm calling for help, in case anyone has an idea about that. Basically, is there a way to say to gvim always open files in a remote server, run it if it's not already running using the config file and not an argument (so I don't mess with the command line). I do need the servername to be desktop specific though, so it's still a difficulty. NOTE: I know that emacs has some kind of remote server habilities too, but I'm not sure how it works and if it'd be possible to do that in emacs, and I'm not really an emacs user and don't really intend to switch. If you have any idea, feel free to comment (by mail), I might do a later post when I have an enhanced solution.

Yesterday, stardict-czech got accepted to Debian. So there is yet another useful dictionary for Czech users available in Debian without need to use my repository (however daily builds are still available there). The dictionary is built from ABZ.cz: slovn k ciz ch slov using my set of scripts, which are also capable of converting other dictionaries. Thanks to FTP masters team for accepting new package even in freeze, when they are busy with other things. Great work guys.

Filed under: Debian Stardict 0 comments Flattr this!

Another one, just not to forget it, since I'm just starting to play with grsecurity. When building package under pbuilder/cowbuilder and using a grsec kernel, you have some stuff to tune. I built my grsec kernel with the sysctl options enabled, so it's easier to fix. The first thing I needed, not directly related to building packages, is the permission for my user to execute stuff in untrusted folder (since I really need to be able to run stuff from my home). I've configured Trusted Path Execution with:

corsac@hidalgo: sudo sysctl -a grep kernel.grsecurity.tpe
kernel.grsecurity.tpe = 1
kernel.grsecurity.tpe_gid = 500
kernel.grsecurity.tpe_invert = 1
kernel.grsecurity.tpe_restrict_all = 1 So what I need from there is to add my user to that group:

corsac@hidalgo: sudo addgroup --gid 500 grsec-tpe
Adding group grsec-tpe' (GID 500) ...
Done.
corsac@hidalgo: sudo adduser corsac grsec-tpe
Adding user corsac' to group grsec-tpe' ...
Adding user corsac to group grsec-tpe
Done. That works fine for general usage (at the cost of less protection for my user). When trying to build stuff in pbuilder, the first problem I hit was during dependencies installation:

[81903.221359] grsec: From 127.0.0.6: denied chmod +s
of /home/corsac/debian/pbuilder/build/cow.8616/usr/local/share/sgml/stylesheet
by /home/corsac/debian/pbuilder/build/cow.8616/bin/chmod[chmod:10424] uid/euid:0/0 gid/egid:0/0,
parent /home/corsac/debian/pbuilder/build/cow.8616/var/lib/dpkg/info/sgml-base.postinst[sgml-base.posti:10421] uid/euid:0/0 gid/egid:0/0 grsec enforces some more protection when in a chroot, and especially forbids some operations in there. So I add an exception, using sysctl. For that, a convenient /etc/sysctl.conf.d/grsec.conf will help:

# we need to do stuff in chroots for package building
kernel.grsecurity.chroot_deny_chmod=0

# lock grsec sysctl
# kernel.grsecurity.grsec_lock=1 The last one is still in comment since I know I'll have to tune further the sysctl. With this, the build-deps install fine, but when starting the build itself, it fails because I can't execute stuff inside chroot, and especially not debian/rules:

Sep 20 19:43:24 hidalgo kernel: [87339.510137] grsec: From 127.0.0.6: denied untrusted exec of
/home/corsac/debian/pbuilder/build/cow.26657/tmp/buildd/evolution-data-server-2.30.3/debian/rules by
/home/corsac/debian/pbuilder/build/cow.26657/usr/bin/fakeroot-sysv[fakeroot:10916] uid/euid:1234/1234 gid/egid:1234/1234,
parent /home/corsac/debian/pbuilder/build/cow.26657/usr/bin/fakeroot-sysv[fakeroot:10895] uid/euid:1234/1234 gid/egid:1234/1234 That's again because of TPE. Because, inside the chroot, the pbuilder user (uid 1234) doesn't belong to the grsec-tpe group (which doesn't even exist). So the correct fix here is to create a 500 group inside the chroot, and add the pbuilder user:

corsac@hidalgo: sudo cowbuilder --login --save-after-login
-> Copying COW directory
[ ]
root@hidalgo:/# sudo addgroup --gid 500 grsec-tpe
Adding group grsec-tpe' (GID 500) ...
Done.
root@hidalgo:/# sudo adduser pbuilder grsec-tpe
Adding user pbuilder' to group grsec-tpe' ...
Adding user pbuilder to group grsec-tpe
Done. Et voil !